-
Notifications
You must be signed in to change notification settings - Fork 15.4k
[libc] provide binary compatibility with syscall symbol #117229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
@llvm/pr-subscribers-libc Author: Schrodinger ZHU Yifan (SchrodingerZhu) ChangesFull diff: https://github.com/llvm/llvm-project/pull/117229.diff 9 Files Affected:
|
|
Mind adding a description to this PR? |
|
Ah, sorry I missed it when committing. |
|
I'm not sure why this is necessary. We already have an implementation of It's got a different name that's translated through a macro in the |
|
For example, rust std assumes syscall. |
I think the problem is that even though we do not assume ABI compatibility with glibc compiled programs, in current approach, we are not providing standard means to programs outside C/C++ to do platform-agnostic syscall. |
|
IIUC, it looks like the rust std lib is expecting to use C FFI to do syscalls: https://codebrowser.dev/rust/rust/library/std/src/sys/pal/unix/weak.rs.html#158 IIUC, it doesn't matter if our syscall is a macro, if the runtime of the higher level language expects syscall to be a symbol and can't use the C preprocessor (such as rust). |
|
@nickdesaulniers yes, but maybe we should ask them to change instead if they are to support LLVM's libc? I am open for discussion. e.g. they can use |
Glibc and MUSL both provides
syscallas a binary. Inside LLVM-libc, we provides it as a macro backed by__llvm_libc_syscallwhich is not binary compatible with other implementations. This PR provides the symbol for better compatibility for those applications assuming the existence of the symbol.